# 前言

是时候再祭出这张图了，由于时间有限（虚拟机也崩了。。不会熟悉的人还是上云服务器吧），这一章的内容更多的是提供解决方案与思路，大家可以根据自己的项目情况，来融入整体流程中即可。

前面的 Devops 主要集成了 Gitlab 与 Jenkins，发布我们使用的 Nginx（发布静态项目）与 Rancher（发布 node 服务）。代码静态扫描使用了 Sonar，埋点与性能监控使用的是 Sentry。其中 Rancher 、Sentry、Sonar 都是独立的模块，并没有接入 Devops，本章将会结合之前的设计，将这些内容纳入到 Devops 体系中去。

# 接入的设计

在前面三章介绍的，不知道大家有没有留意，每个模块都与我们的 Devops 流程设计中存在 2 个相通的地方：

1. 项目（无论何种方式都是基于 Gitlab 的项目构建出来）
2. 版本（无论是基于 Branch 还是自定义的版本都有 Version 的概念）

而在我们的 Devops 中，采用的自建 Version 与 Branch 绑定的关系，所以我们在对接各个模块的时候，可以通过对应的项目与版本进行关联，使用每个模块提供的 Web API 将需要的数据或者对应的操作集成到 Devops 工程中。

接下来，我们将以 Senrty 为例子，介绍集成的方案。

# Sentry 集成

# Sentry Api

下图是 Sentry 对应的 Web Api 接口文档，可以挑选一些需要集成到我们项目中的接口配合即可。

首先，基于 Gitlab，我们可以获取到对应的 Group 的信息，那么每个 Group 可以映射到对应的 Senrty 的 Teams。

所以在 Devops 中，当用户进来之后，所属的 Group 映射到 Sentry 就是对应的 Teams 信息，比较简单的操作是 Group 与 Teams name 保持一一对应，这样就不需要新建关联表。

1. 创建项目的时候，通过对应的 API 创建对应的 Project

1. 再项目创建完毕之后，通过 Sentry 提供的 Project 的 Api，创建对应的 DSN。

1. 项目发布到预发环境的时候，创建对应的 Release，并通过构建流程上传对应的 sourcemap。
2. 如果想集成更多的话，可以使用